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DETAILED ACTION 

1. This communication is in response to the Amendment filed 14 July 2009. 

2. Claims 8, 12, 13 and 20-34 are currently pending and claims 1-7, 9-11 and 14-19 
are canceled. In the Amendment filed 14 July 2009, claims 8, 20 and 23 are amended 
and claims 29-34 are new. This action is made Final. 

3. The prior art rejections of the claims have been maintained. 



Claim Rejections - 35 USC §112 

4. The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of 
making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 
set forth the best mode contemplated by the inventor of carrying out his invention. 

5. Claims 8, 12, 13 and 20-34 are rejected under 35 U.S.C. 112, first paragraph, as 
failing to comply with the written description requirement. The claim(s) contains subject 
matter which was not described in the specification in such a way as to reasonably 
convey to one skilled in the relevant art that the inventor(s), at the time the application 
was filed, had possession of the claimed invention. Independent claims 8, 20 and 23 
recite the limitation "responsive to said resolving, converting said obtained attribute 
value from a real-time attribute to a static attribute, wherein said real-time attribute is 
incompatible with said directory access protocol, and wherein said static attribute is 
compatible with said directory access protocol" and "returning to a requester said 
converted real-time attribute directly in said directory access protocol, wherein storing 
and updating of said converted real-time attribute value in said directory structure is 
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eliminated or avoided." The examiner fails to find support within the specification for 
this limitation in application with the other claimed limitations. Since the dependent 
claims fail to overcome the rejections of the independent claims, claims 9-13, 21, 22 
and 24-34 are rejected on the same grounds. 

Claim Rejections - 35 USC § 103 

6. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

This application currently names joint inventors. In considering patentability of the 
claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of the 
various claims was commonly owned at the time any inventions covered therein 
were made absent any evidence to the contrary. Applicant is advised of the 
obligation under 37 CFR 1 .56 to point out the inventor and invention dates of each 
claim that was not commonly owned at the time a later invention was made in order 
for the examiner to consider the applicability of 35 U.S.C. 103(c) and potential 35 
U.S.C. 102(e), (f) or (g) prior art under 35 U.S.C. 103(a). 

7. Claims 8, 12, 13 and 20-34 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over US PGPub 2002/0147857 to Sanchez, II et al (hereafter 
Sanchez) in view of US PGPub 2008/0086402 to Patel et al (hereafter Patel) in view 
of US PGPub 2003/0120502 to Robb et al (hereafter Robb). 
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Referring to claim 8, Sanchez discloses a method comprising: 

providing at least one declaration for a directory attribute (see [0050]); 

receiving a directory protocol request for access to one or more attribute values 
from said associated directory structure (see [0056]); 

invoking at least one Real-Time Attribute Processor (RTAP) selector from a 
plurality of attribute processor according to a predetermined selection schema and to 
invoke said selected RTAP (see [0030], lines 7-15); and 

returning to a requester said attribute value [populating the object] (see [0062]). 

However, Sanchez fails to explicitly disclose the further limitations wherein the 
attributes are to be handled as a real-time attribute associated with but external to a 
directory structure; detecting in said received request a request to access an attributed 
as a real-time external attribute; and responsive to said detecting of a request for a real- 
time attribute, resolving a real-time value by obtaining an attribute value from a real-time 
source external to said directory structure. Patel discloses wherein the attributes are to 
be handled as a real-time attribute associated with but external to a directory structure; 
detecting in said received request a request to access an attributed as a real-time 
external attribute; and responsive to said detecting of a request for a real-time attribute, 
resolving a real-time value by obtaining an attribute value from a real-time source 
external to said directory structure [attributes fetched in real-time] and being in a format 
incompatible with a directory access return format and obtaining an attribute value from 
a real-time source external to said directory structure (see [0074] and [1056]). 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention to utilize concept of fetching dynamic attributes in real-time as disclosed by 
Patel with the logical device of Sanchez. One would have been motivated to so in order 
to introduce the concept of providing customer personalization in real-time to Sanchez 
which increases accuracy of the dynamic data and decreases the resources required to 
poll and push dynamic data to the LDAP (Patel: see [0005]). 

The combination of Sanchez/Patel (hereafter Sanchez/Patel) fails to explicitly 
disclose the further limitations of responsive to said resolving, converting said obtained 
attribute value from a real-time attribute to a static attribute, wherein said real-time 
attribute is incompatible with said directory access protocol, and wherein said static 
attribute is compatible with said directory access protocol and returning to a requester 
said converted real-time attribute directly in said directory access protocol, wherein 
storing and updating of said converted real-time attribute value in said directory 
structure is eliminated or avoided. Robb discloses directory services, including the 
further limitations of responsive to said resolving, converting said obtained attribute 
value from a real-time attribute to a static attribute, wherein said real-time attribute is 
incompatible with said directory access protocol, and wherein said static attribute is 
compatible with said directory access protocol and returning to a requester said 
converted real-time attribute directly in said directory access protocol, wherein storing 
and updating of said converted real-time attribute value in said directory structure is 
eliminated or avoided [dynamic content verses static content] (see [0074] and [0076]). 
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It would have been obvious to one of ordinary skill in the art at the time of the 
invention to utilize steps of Robb for reformatting and retrieving the attribute value in 
real-time with the steps of Sanchez/Patel. One would have been motivated to do so in 
order to make the system compatible with a plurality of resources and applications and 
also to reduce the amount of storage required. 

Referring to claim 12, Sanchez/Patel/Robb discloses the method as set forth in 
claim 8 wherein said detecting comprises parsing a request comprises parsing a 
Lightweight Directory Access Protocol [LDAP] requests for attribute values (Sanchez: 
see [0008]). 

Referring to claim 13, Sanchez/Patel/Robb discloses the method as set forth in 
claim 8 wherein said returning comprises returning said value according to a 
Lightweight Directory Access Protocol (Sanchez: see [0008]). 

Referring to claim 20, Sanchez discloses a computer readable memory 
comprising: a computer readable memory suitable for encoding computer programs; 
and one or more computer programs encoded by said computer readable memory (see 
Fig 1 ) and configured to: 

provide at least one declaration for a directory attribute (see [0050]); 

receive a directory protocol request for access to one or more attribute values 
from said associated directory structure (see [0056]); 

invoke at least one Real-Time Attribute Processor (RTAP) selector from a 
plurality of attribute processor according to a predetermined selection schema and to 
invoke said selected RTAP (see [0030], lines 7-15); and 
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return to a requester said attribute value [populating the object] (see [0062]). 

However, Sanchez fails to explicitly disclose the further limitations wherein the 
attributes are to be handled as a real-time attribute associated with but external to a 
directory structure; detect in said received request a request to access an attributed as 
a real-time external attribute; and responsive to said detecting of a request for a real- 
time attribute, resolve a real-time value by obtaining an attribute value from a real-time 
source external to said directory structure. Patel discloses wherein the attributes are to 
be handled as a real-time attribute associated with but external to a directory structure; 
detect in said received request a request to access an attributed as a real-time external 
attribute; and responsive to said detecting of a request for a real-time attribute, resolving 
a real-time value by obtaining an attribute value from a real-time source external to said 
directory structure [attributes fetched in real-time] and being in a format incompatible 
with a directory access return format and obtaining an attribute value from a real-time 
source external to said directory structure (see [0074] and [1056]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to utilize concept of fetching dynamic attributes in real-time as disclosed by 
Patel with the logical device of Sanchez. One would have been motivated to so in order 
to introduce the concept of providing customer personalization in real-time to Sanchez 
which increases accuracy of the dynamic data and decreases the resources required to 
poll and push dynamic data to the LDAP (Patel: see [0005]). 

The combination of Sanchez/Patel (hereafter Sanchez/Patel) fails to explicitly 
disclose the further limitations of responsive to said resolving, converting said obtained 
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attribute value from a real-time attribute to a static attribute, wherein said real-time 
attribute is incompatible with said directory access protocol, and wherein said static 
attribute is compatible with said directory access protocol and returning to a requester 
said converted real-time attribute directly in said directory access protocol, wherein 
storing and updating of said converted real-time attribute value in said directory 
structure is eliminated or avoided. Robb discloses directory services, including the 
further limitations of responsive to said resolving, converting said obtained attribute 
value from a real-time attribute to a static attribute, wherein said real-time attribute is 
incompatible with said directory access protocol, and wherein said static attribute is 
compatible with said directory access protocol and returning to a requester said 
converted real-time attribute directly in said directory access protocol, wherein storing 
and updating of said converted real-time attribute value in said directory structure is 
eliminated or avoided [dynamic content verses static content] (see [0074] and [0076]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to utilize steps of Robb for reformatting and retrieving the attribute value in 
real-time with the steps of Sanchez/Patel. One would have been motivated to do so in 
order to make the system compatible with a plurality of resources and applications and 
also to reduce the amount of storage required. 

Referring to claim 21, Sanchez/Patel/Robb discloses the computer readable 
memory as set forth in claim 20 wherein said detecting comprises parsing a Lightweight 
Directory Access Protocol [LDAP] requests for attribute values (Sanchez: see [0008]). 
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Referring to claim 22, Sanchez/Patel/Robb discloses the computer readable 
memory as set forth in claim 20 wherein said returning comprises returning said value 
according to a Lightweight Directory Access Protocol (Sanchez: see [0008]). 

Referring to claim 23, Sanchez discloses a system comprising hardware means 
for performing a logical process, wherein said logical process comprises: 

providing at least one declaration for a directory attribute (see [0050]); 

receiving a directory protocol request for access to one or more attribute values 
from said associated directory structure (see [0056]); 

invoking at least one Real-Time Attribute Processor (RTAP) selector from a 
plurality of attribute processor according to a predetermined selection schema and to 
invoke said selected RTAP (see [0030], lines 7-15); and 

returning to a requester said attribute value [populating the object] (see [0062]). 

However, Sanchez fails to explicitly disclose the further limitations wherein the 
attributes are to be handled as a real-time attribute associated with but external to a 
directory structure; detecting in said received request a request to access an attributed 
as a real-time external attribute; and responsive to said detecting of a request for a real- 
time attribute, resolving a real-time value by obtaining an attribute value from a real-time 
source external to said directory structure. Patel discloses wherein the attributes are to 
be handled as a real-time attribute associated with but external to a directory structure; 
detecting in said received request a request to access an attributed as a real-time 
external attribute; and responsive to said detecting of a request for a real-time attribute, 
resolving a real-time value by obtaining an attribute value from a real-time source 
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external to said directory structure [attributes fetched in real-time] and being in a format 
incompatible with a directory access return format and obtaining an attribute value from 
a real-time source external to said directory structure (see [0074] and [1056]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to utilize concept of fetching dynamic attributes in real-time as disclosed by 
Patel with the logical device of Sanchez. One would have been motivated to so in order 
to introduce the concept of providing customer personalization in real-time to Sanchez 
which increases accuracy of the dynamic data and decreases the resources required to 
poll and push dynamic data to the LDAP (Patel: see [0005]). 

The combination of Sanchez/Patel (hereafter Sanchez/Patel) fails to explicitly 
disclose the further limitations of responsive to said resolving, converting said obtained 
attribute value from a real-time attribute to a static attribute, wherein said real-time 
attribute is incompatible with said directory access protocol, and wherein said static 
attribute is compatible with said directory access protocol and returning to a requester 
said converted real-time attribute directly in said directory access protocol, wherein 
storing and updating of said converted real-time attribute value in said directory 
structure is eliminated or avoided. Robb discloses directory services, including the 
further limitations of responsive to said resolving, converting said obtained attribute 
value from a real-time attribute to a static attribute, wherein said real-time attribute is 
incompatible with said directory access protocol, and wherein said static attribute is 
compatible with said directory access protocol and returning to a requester said 
converted real-time attribute directly in said directory access protocol, wherein storing 



Application/Control Number: 10/809,583 Page 11 

Art Unit: 2167 

and updating of said converted real-time attribute value in said directory structure is 
eliminated or avoided [dynamic content verses static content] (see [0074] and [0076]). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention to utilize steps of Robb for reformatting and retrieving the attribute value in 
real-time with the steps of Sanchez/Patel. One would have been motivated to do so in 
order to make the system compatible with a plurality of resources and applications and 
also to reduce the amount of storage required. 

Referring to claim 24, Sanchez/Patel/Robb discloses the system as set forth in 
Claim 23 wherein said hardware means comprises at least in part a microprocessor 
(Sanchez: see Fig 1). 

Referring to claim 25, Sanchez/Patel/Robb discloses the system as set forth in 
Claim 23 wherein said hardware means comprises at least in part an electronic circuit 
(Sanchez: see Fig 1). 

Referring to claim 26, Sanchez/Patel/Robb discloses the system as set forth in 
Claim 25 wherein said electronic circuit is selected from a group comprising an 
application specific integrated circuit, and a programmable logic circuit (see Fig 1). 

Referring to claim 27, Sanchez/Patel/Robb discloses the system as set forth in 
claim 23 wherein said detecting comprises parsing a request comprises parsing a 
Lightweight Directory Access Protocol [LDAP] requests for attribute values (Sanchez: 
see [0008]). 
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Referring to claim 28, Sanchez/Patel/Robb discloses the method as set forth in 
claim 23 wherein said returning comprises returning said value according to a 
Lightweight Directory Access Protocol (Sanchez: see [0008]). 

Referring to claim 29, Sanchez/Patel/Robb discloses the method of Claim 8 
wherein said resolving a real-time value by obtaining an attribute value from a real-time 
source external to said directory structure further comprises selecting according to a 
predetermined selection schema a real-time attribute processor from a plurality of 
available real-time attribute processors, invoking said selected real-time attribute 
processor, and wherein said resolving is performed by said invoked real-time attribute 
processor (Sanchez: see [0030], lines 7-15). 

Referring to claims 31 and 33, the claims are rejected on the same grounds as 
claim 29. 

Referring to claim 30, Sanchez/Patel/Robb discloses the method of Claim 29 
wherein said predetermined selection schema comprises a schema employing a 
variation of a name of said requested directory attribute to identify a real- time attribute 
processor for selection (Sanchez: see [0030], lines 7-15). 

Referring to claims 32 and 34, the claims are rejected on the same grounds as 
claim 30. 

Response to Arguments 

8. Applicant's arguments filed 14 July 2009 have been fully considered but they are 
not persuasive. 
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9. Referring to Applicant's arguments on page 8 of the Remarks, the Applicant 

states the following: 

With respect to the rejections regarding whether or not the Applicant(s) 
possessed the invention aspects "responsive to said resolving, converting said 
obtained attribute value from a first value format to a second value format, 
wherein said first value format is incompatible with said directory access protocol, 
and wherein said second value format is compatible with said directory access 
protocol", we respectfully disagree. Compatibility Conversion. Please note that in 
our H001 1 (as numbered in the pre-grant publication), we introduced the history 
of incompatible and proprietary protocols which were well known in the industry. 
Then, in 1J0012, we discussed the open standard X.500 for directory services, 
and that various directory server protocol extension approaches (e.g. "add-ons") 
have been taken to provide bridging technologies between X.500 and protocols 
which are not X.500 compatible. Please also see our 1H10087 and 0137, in which 
we describe our own "extension" to the directory server to allow for compatibility 
between old directory servers and new directory servers employing our invention. 
Regarding "converting" data to be LDAP compatible, per se, please see our 
Figure 4, which is described in 1J0057 as illustrating conversion of dynamic data 
(e.g. time-varying data) to static data for storage in an LDAP directory. We 
contend that no art of record shows a standard LDAP directory storing anything 
other than static data, but if the Examiner disagrees, we respectfully ask for the 
Examiner to provide any extrinsic evidence or an affidavit of knowledge (37 
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C.F.R. § 1.104(d)(2)). Otherwise, we believe that dynamic data is inherently 
incompatible with storage in an LDAP directory. 

In response to Applicant's arguments, it is noted that Paragraph [0012] and 
Figure 4 teaches what has been done in the past as it is labeled prior art. Paragraph 
[0049] states how corresponding dynamic attributes in an LDAP directory are refreshed 
and stored. 

Referring to Applicant's arguments on page 9 of the Remarks, the Applicant 
states the following: 

"Responsive to... ". Regarding the phrase "responsive to said resolving, 
converting said obtained attribute value from a first value format to a second 
value format, ... ", we respectfully point out that the decision block #82 of Figure 8 
shows responding to determining that the attribute is "real-time" (e.g. dynamic), 
then invoking a real-time attribute processor (RTAP). Please note that Figure 5 
shows the RTAP getting the current value (#62) of the requested real- time value 
so that it can be returned to the requester (application 2 #23). Please note that 
H0 131 states "... the appropriate RTAP (51) process or method, which in turn 
retrieves or otherwise determines (62) current real-time value of the attribute(s) 
based upon a dynamic data source (54). These real-time values then are 
returned (34") to the LDAP server and the requesting client (23) as if it were a 
normal result from a static attribute return. " 

The examiner agrees that paragraph [0131] states that the RTAP method 
retrieves the real-time value of the dynamic data source. As is also stated in paragraph 
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[0086], "The function currentTemp.so in our prototype actually accesses real-time data 
from the ounline resource "weather.com," parses the data, and returns the value "82F" 
to the LDAP directory server which then combines that information with the other static 
information from the LDAP directory, and passes it back to the requesting client." 
Paragraph [0087] states that the value was never stored or retrieved from the LDAP 
directory. Therefore, the Specification fails to teach that Applicant's invention converts 
the retrieved value. The Specification only teaches that the value had to be converted 
in the prior art when it was stored in the directory. 

Referring to Applicant's arguments on pages 10-1 1 of the Remarks, the Applicant 
states the following: 

Regarding the rejections over newly-cited Robb in combination with Sanchez and 
Patel, we respectfully disagree that Robb teaches converting the real-time value 
from a first non- compatible format to a second compatible format. It was argued 
that Robb teaches our claimed conversion from a first format (now recited as a 
directory access protocol incompatible real-time attribute) to a second format 
(now recited as a directory access protocol compatible static attribute). Please 
note that we have amended the claims slightly to clarify that the real-time 
attribute value is originally incompatible with a directory access protocol 
(corresponding to a "first format"), and that it is converted to a static attribute 
compatible with a directory access protocol (corresponding to a "second format"). 
As stated above, the Examiner fails to find support for the limitation within the 
specification. 
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10. The novelty of the invention appears to be centered around newly added claims 
29-34 in conjunction with paragraphs [0068]-[0076]. It is suggested that the Applicant 
incorporate this subject matter into the independent claims. 



Conclusion 

1 1 . THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 . 1 36(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 
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